5.2 KB · ⇊ 2 parts · ⤓ Micron 5.2 KB · ⤓ HTML 11.7 KB

top

Unter Extended DNS (EDNS) werden verschiedene Protokoll-Erweiterungen des Domain Name Systems (DNS) zusammengefasst, die den Transport von DNS-Daten in UDP-Paketen betreffen.

• Motivation

• Funktionsweise

• Praxis

• Normen und Standards

• Einzelnachweise

Das in der ersten Hälfte der 1980er entwickelte DNS wurde im Laufe der Jahre mit zahlreichen weiteren Funktionen ausgestattet. Die in DNS-Paketen vorhandenen Flags, Returncodes und Label-Typen reichten schließlich nicht mehr aus, alle Situationen zu beschreiben. Ein weiteres gravierendes Problem ergab sich aus der Längenbeschränkung des DNS-UDP-Pakets von 512 Bytes. Diese Einschränkungen machten eine Erweiterung des DNS-Paket-Formats unumgänglich. 1999 wurde von Paul Vixie im RFC 2671cite-ref-rfc2671-1-0[1] ein entsprechender Standard formuliert.

Da im DNS-Header kein Flag mehr zur Verfügung stand, um zwischen herkömmlichem und EDNS-Format zu unterscheiden, wurde ein sogenannter Pseudo-Record eingeführt, der sogenannte OPT Resource Record. Ein derartiger Pseudo-RR wird nur auf dem Transportweg zwischen Client und Server verwendet. Er erscheint niemals in Zonendateien oder in Caches. Ein DNS-Teilnehmer, der ein DNS-Paket als EDNS kennzeichnen möchte, fügt einen entsprechenden Pseudo-RR in die Additional Data Section der DNS-Anfrage oder -Antwort ein.

Neben der Aufgabe, ein Paket als EDNS-Paket zu markieren, hat ein OPT-Resource-Record folgende Funktionen:

• Bereitstellung von 16 zusätzlichen Flags

• Erweiterung des Response-Codes um acht Bytes (damit können in einem Paket insgesamt drei Response-Codes untergebracht werden)

Außerdem sind die Gesamtlänge des UDP-Pakets und die Versions-Nummer (zurzeit 0) enthalten. In einem Datenfeld variabler Länge können zukünftig weitere Informationen eingetragen werden.

Eine weitere im RFC 2671cite-ref-rfc2671-1-1[1] spezifizierte Erweiterung bezieht sich auf das Label-Format. Ursprünglich gab es in DNS-Paketen zwei Label-Typen, die durch die ersten beiden Bits definiert werden (RFC 1035cite-ref-2[2]):

• 00 = Standard-Label

• 11 = komprimiertes Label

Um eine größere Anzahl weiterer Label-Typen zu ermöglichen, wird der Typ 01 = "Extended Label" definiert. Aus den folgenden 6 Bits des ersten Bytes können damit insgesamt 63 Label-Untertypen gebildet werden.

EDNS ist bei DNSSEC zwingend notwendig, da das DO-Flag (DNSSEC OK) nicht mehr im Standard-Header untergebracht werden kann. Das DO-Flag ist auch das erste neu definierte Flag.

Im Zusammenhang mit älteren Firewalls können Schwierigkeiten auftreten, wenn diese von einer maximalen DNS-Nachrichten-Länge von 512 Bytes ausgehen und längere Pakete verwerfen.cite-ref-3[3]

Beispiel der Darstellung von OPT-Daten bei der Ausgabe des dig-Tools:

• RFC: 2671 – Extension Mechanisms for DNS (EDNS0). 1999 (englisch).

cite-note-rfc2671-11. ↑ RFC: 2671 – Extension Mechanisms for DNS (EDNS0). 1999 (englisch).

cite-note-22. ↑ RFC: 1035 – Domain Names – Implementation and Specification. (englisch).

cite-note-33. ↑ Nach der Bereitstellung eines Windows-basierten DNS-Servers sind einige DNS-Namensabfragen nicht erfolgreich. In: Microsoft Support. 24. April 2017, abgerufen am 28. Januar 2019.